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20 FIELD OF THE INVENTION 

The present invention relates to methods and apparatus for facilitating 

commerce. 
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BACKGROUND OF THE INVENTION 

There is a great deal of competition among vendors to attract and retain 
customers. Even when a customer has browsed a vendor's inventory, he will not 
make a purchase if an item's price is greater than the amount the customer is willing to 
pay. One way to increase customer willingness to purchase is to provide discounts on 
items purchased. Unfortunately, vendors must use discounts sparingly, since reducing 
purchase prices likewise reduces margins and the reduced margins may not be offset 
by increased sales volume. 

A vendor may also offer promotions to provide an incentive for 
customers to make purchases. For example, a vendor may offer a "buy one get one 
free" promotion whereby a purchase of an item yields the benefit of an additional item 
at no cost. Similarly, a vendor may provide a discount on a purchase in exchange for 
signing up for a credit card account provided by the vendor. 

Promotions may also be provided among two or more vendors. For 
example, a first vendor may advertise that if a particular product is purchased, another 
product may be purchased from or given away by a second vendor. 

The parent application of the present application, U.S. Patent 
Application No. 09/219,267 entitled "METHOD AND APPARATUS FOR 
FACILITATING ELECTRONIC COMMERCE THROUGH PROVIDING CROSS- 
BENEFITS DURING A TRANSACTION", filed on December 23, 1998, discloses a 
method and apparatus that permits a customer that is purchasing items from a first 
vendor to receive a benefit (e.g. a credit for the price of the items) from a second 
vendor. The present application provides further embodiments of this novel and 
beneficial invention. 



SUMMARY OF THE INVENTION 

It is an object of the present invention to provide a method and 
apparatus for facilitating commerce. 

In accordance with the present invention, a controller is in 
communication with a plurality of vendors that are servicing customers, as well as 
with a plurality of "subsidizing" vendors seeking access to those customers. The 
controller receives from a first vendor server an indication of one or more items that a 
customer is to purchase. In response, the controller transmits, on behalf of a 
subsidizing vendor, an indication of an offer for a subsidy such as a reduction in the 
customer's purchase price. 

If the customer accepts the offer, the controller provides, directly or 
indirectly, an amount of funds from the subsidizing vendor to the first vendor. The 
controller may retain a portion of the amount of funds as payment. The controller 
also facilitates a transaction between the customer and the subsidizing vendor. For 
example, the customer may be required to sign up for a service (e.g. credit card 
account service) that is provided by the subsidizing vendor. The controller may 
facilitate this transaction by providing a form for entry of customer information. 

By having the controller manage such a system by acting between 
subsidizing vendors and vendors that are servicing customers, a vendor need only 
communicate with the controller, rather than a plurality of other vendors. Vendors 
likewise need only form one relationship with a central authority rather than with a 
plurality of other vendors. Furthermore, as new subsidizing vendors elect to 
participate, existing vendors automatically benefit from the new subsidies which may 
be possible. 



BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a schematic illustration of an apparatus for facilitating commerce in 
accordance with the present invention. 

FIG. 2 is a schematic illustration of a controller of the apparatus of FIG. 1. 

FIG. 3 is a schematic illustration of a vendor server of the apparatus of FIG. 1. 

FIG. 4 is a representation of a customer database of the controller of FIG. 2. 

FIG. 5 is a representation of a vendor database of the controller of FIG. 2. 

FIG. 6 is a representation of a transaction database of the controller of FIG. 2. 

FIG. 7 is a representation of a subsidizer database of the controller of FIG. 2. 

FIG. 8 is a representation of an offer rules database of the controller of FIG. 2. 

FIG. 9 is a representation of an offers database of the controller of FIG. 2. 

FIG. 10 is a representation of a record of an offer summary database of the 
controller of FIG. 2. 

FIG. 1 1 is a schematic illustration of an item database of the vendor server of 

FIG. 3. 

FIG. 12 is a flow chart illustrating an embodiment of a method, performed by 
a vendor server, for providing an offer for a benefit. 

FIG. 1 3 is a flow chart illustrating an embodiment of a method, performed by 
the controller of FIG. 2, for providing an offer for a benefit. 

FIG. 14 is an exemplary web page. 

FIG. 15 is another exemplary web page. 

FIG. 1 6 is a flow diagram illustrating the transfer of funds among parties in 
accordance with the present invention. 

FIGS. 17A and 17B are a flow chart illustrating another embodiment of a 
method for providing an offer for a benefit to a customer. 



FIGS. 1 8 A and 1 8B are a flow chart illustrating another embodiment of a 
method for providing an offer for a benefit to a customer. 

FIG. 19 is a flow chart illustrating another embodiment of a method for 
providing an offer for a benefit to a customer. 

FIGS. 20A and 20B are a flow chart illustrating another embodiment of a 
method for providing an offer for a benefit to a customer. 

FIG. 21 is a table illustrating data used when a subsidy amount is applied over 

time. 

FIG. 22 is a flow chart illustrating another embodiment of a method for 
providing an offer for a benefit to a customer. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

Applicants have recognized that the acquisition budgets of various 
venders may be advantageously used to facilitate commerce. A customer that 
purchases items from a first vendor may be paid, directly or indirectly, by a second 
vendor, so that the customer pays a reduced price, perhaps nothing at all, for his 
desired items. In exchange, the customer participates or agrees to participate in a 
transaction with the second vendor. As used herein, this "transaction" may be any 
interaction with the second vendor. For example, the customer may be required to 
sign up for a service that is provided by the second vendor. Since many service 
providers are willing to pay significant amounts of money (e.g. often $50 to $200) to 
acquire a new customer, the ability to acquire a customer by essentially "intervening" 
in a sale between others can benefit all parties involved. The customer is benefited by 
the reduced price of his items, the first vendor is benefited by the increased sales and 
customer satisfaction that such an arrangement would bring, and the second vendor is 



benefited by the additional transaction, particularly the acquisition of a new customer 
in one embodiment. 

In addition, applicants have also recognized that there are benefits to 
having a controller manage such a system by acting between subsidizing vendors and 
vendors that are servicing customers. For example, a vendor need only communicate 
with the controller, rather than with a plurality of other vendors. Vendors likewise 
need only form one relationship with a central authority rather than with a plurality of 
other vendors. Furthermore, as new subsidizing vendors elect to participate, existing 
vendors automatically benefit from the new subsidies which may be possible. 

The controller of the present invention can also track customer 
information derived from several vendors, allowing subsidies to be better targeted to 
customers. The controller can also act to reduce or eliminate customer manipulation 
of subsidy offers. For example, the controller can identify a customer that attempts to 
merely collect subsidies by agreeing to participate in contradictory transactions, such 
as simultaneously agreeing to switch to two telephone service providers. 

Referring to FIG. 1, an apparatus 100 includes a controller 110 that is 
in communication with vendor servers 120 and 130. The controller 110 and the 
vendor servers 120 and 130 may comprise computers, such as those based on an 
Intel® Pentium® microprocessor, that are adapted to communicate via the Internet 
(e.g. via a modem) or other medium. Any number of vendor servers may be in 
communication with the controller 110. 

Each of the vendor servers 120 and 130 may be a "web server" of a 
vendor (e.g. a retail seller). A vendor server could then generate a web page that may 
be accessed via the World Wide Web and allow purchases from the vendor to be 
made in a manner known in the art. Alternatively, each of the vendor servers 120 and 



130 may be a computer involved in operating a physical store. Such a computer, for 
example a point of sale (POS) server, would perform such tasks as inventory 
management and item pricing. 

The controller 1 10 is also in communication with subsidizing vendor 
servers 140, 150 and 160. Each of the subsidizing vendor servers 140, 150 and 160 
may comprise computers, such as those based on the Intel® Pentium® 
microprocessor, that are adapted to communicate via the Internet (e.g. via a modem) 
or other medium. Any number of subsidizing vendor servers may be in 
communication with the controller 110. 

Each of the subsidizing vendor servers 140, 150 and 160 may be a 
"web server" of a vendor. A subsidizing vendor server could then generate a web 
page that may be accessed via the World Wide Web and allow transactions with the 
subsidizing vendor in a manner known in the art. Alternatively, each of the 
subsidizing vendor servers 140, 150 and 160 may be a computer involved in operating 
a physical store. Such a computer would perform such tasks as inventory 
management and item pricing. 

A vendor server may be in communication with one or more customer 
terminals that transmit data on a customer transaction (e.g. a purchase). The vendor 
server 120 is in communication with a customer terminal 170, and the vendor server 
1 30 is in communication with customer terminals 1 80 and 1 90. Any or all of the 
customer terminals 170, 180 and 190 may be point of sale (POS) terminals, such as 
the NCR 7454 manufactured by NCR Corporation or the IBM 4683 manufactured by 
International Business Machines. As is known in the art, POS terminals perform such 

processes as calculating the total price of a purchase (goods or services) and 
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calculating the amount of change due to a customer. POS terminals may furthermore 
track purchases made and adjust databases of inventory accordingly. 

In another embodiment, any or all of the customer terminals 170, 180 
and 1 90 may be computers, such as those based on the Intel® Pentium® 
microprocessor, that are adapted to communicate via the Internet (e.g. via a modem) 
or other medium. Such computers are able to appropriately access a web page to 
communicate with a vendor server in a manner that is known to those skilled in the 
art. 

In still other embodiments, any or all of the customer terminals 170, 
180 and 190 may be telephones, vending machines, other devices that can receive 
payment from customers in exchange for providing goods or services, pagers or 
palmtop computers such as personal digital assistants (PDAs). 

Referring to FIG. 2, the controller 110 comprises a processor 200, such 
as the Intel® Pentium® microprocessor. The processor 200 is in communication with 
a data storage device 210, such as an appropriate combination of magnetic, optical 
and/or semiconductor memory. For example, the data storage device 210 may 
comprise one or more of a ROM, RAM and hard disk. The processor 200 and the 
data storage device 210 may each be (i) located entirely within a single computer or 
other computing device; (ii) connected to each other by a remote communication 
medium, such as a serial port cable, telephone line or radio frequency transceiver; or 
(iii) a combination thereof. In one embodiment, the controller 110 may comprise one 
or more computers that are connected to a remote server computer for maintaining 
databases. 

The data storage device 210 stores a program 220 for controlling the 
processor 200. The processor 200 performs instructions of the program 220, and 



thereby operates in accordance with the present invention, and particularly in 
accordance with the methods described in detail herein. The program 220 
furthermore includes program elements that may be necessary, such as an operating 
system and "device drivers" for allowing the processor 200 to interface with computer 
peripheral devices. Appropriate device drivers and other necessary program elements 
are known to those skilled in the art, and need not be described in detail herein. 

The storage device 210 also stores (i) a customer database 230, (ii) a 
vendor database 240, (iii) a transaction database 250, (iv) a subsidizer database 260, 
(v) an offer rules database 270, (vi) an offers database 280 and (vii) an offer summary 
database 290. The databases 230, 240, 250, 260, 270, 280 and 290 are described in 
detail below and depicted with exemplary entries in the accompanying figures. As 
will be understood by those skilled in the art, the schematic illustrations and 
accompanying descriptions of the databases presented herein are exemplary 
arrangements for stored representations of information. A number of other 
arrangements may be employed besides those suggested by the tables shown. 
Similarly, the illustrated entries of the databases represent exemplary information, and 
those skilled in the art will understand that the number and content of the entries can 
be different from those illustrated herein. 

Referring to FIG. 3, a vendor server 300 is illustrative of the vendor 

servers 120 and 130 (FIG. 1). The vendor server comprises a processor 302, such as 

the Intel® Pentium® microprocessor, which is in communication with a customer 

terminal 315 and the controller 110. The processor 302 is also in communication with 

a data storage device 310, such as an appropriate combination of magnetic, optical 

and/or semiconductor memory. For example, the data storage device 310 may 

comprise one or more of a ROM, RAM and hard disk. The processor 302 and the 
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data storage device 3 1 0 may each be (i) located entirely within a single computer or 
other computing device; (ii) connected to each other by a remote communication 
medium, such as a serial port cable, telephone line or radio frequency transceiver; or 
(iii) a combination thereof. In one embodiment, the vendor server 300 may comprise 
one or more computers that are connected to a remote server computer for 
maintaining databases. 

The data storage device 310 stores a program 320 for controlling the 
processor 302. The processor 302 performs instructions of the program 320, and 
thereby operates in accordance with the present invention, and particularly in 
accordance with the methods described in detail herein. The program 320 
furthermore includes program elements that may be necessary, such as an operating 
system and "device drivers" for allowing the processor 302 to interface with computer 
peripheral devices. Appropriate device drivers and other necessary program elements 
are known to those skilled in the art, and need not be described in detail herein. 

The storage device 310 also stores (i) a customer database 330, (ii) an 
item database 340, and (iii) a transaction database 350. The customer database 330 
and the transaction database 350 of the vendor server 300 may be similar or identical 
to the customer database 230 and transaction database 250 of the controller 110. For 
example, the controller 110 may store data that is derived from the vendor server 300, 
and vice versa. If each vendor server stores data on its own customers and its own 
transactions, the controller 110 could aggregate this data from each vendor server. 

The databases 330, 340 and 350 are described in detail below and 

depicted with exemplary entries in the accompanying figures. As will be understood 

by those skilled in the art, the schematic illustrations and accompanying descriptions 

of the databases presented herein are exemplary arrangements for stored 

11 



representations of information. A number of other arrangements may be employed 
besides those suggested by the tables shown. Similarly, the illustrated entries of the 
databases represent exemplary information, and those skilled in the art will 
understand that the number and content of the entries can be different from those 
illustrated herein. 

Referring to FIG. 4, a table 400 represents an embodiment of the 
customer database 230 (FIG. 2) and/or the customer database 330 (FIG. 3). The table 
400 includes entries 402, 404, 406 and 408, each defining a customer that may 
purchase items from a vendor. Such information may be determined, for example, 
when a customer registers for a frequent shopper card. Those skilled in the art will 
understand that the table 400 may include any number of entries. The table 400 also 
defines fields for each of the entries 402, 404, 406 and 408. The fields specify (i) a 
customer identifier 420 that uniquely identifies the customer, (ii) a name 422 of the 
customer, (iii) a billing address 424 of the customer, (iv) credit card information 426 
which may be used to render payment in purchasing the items, and (v) an electronic 
mail ("email") address 428 for communication with the customer. 

Referring to FIG. 5, a table 500 represents an embodiment of the 
vendor database 240 (FIG. 2). The table 500 includes entries 502, 504, 506 and 508, 
each defining a vendor that services customers and may have those customers receive 
offers for subsidies. Such information may be determined when a vendor registers for 
participation in the subsidizing program described herein. Those skilled in the art will 
understand that the table 500 may include any number of entries. The table 500 also 
defines fields for each of the entries 502, 504, 506 and 508. The fields specify (i) a 
vendor identifier 520 that uniquely identifies the vendor, (ii) a vendor name 522, (iii) 
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a vendor email address 524 for communication with the vendor, and (iv) an amount 
owed 526 to the vendor (e.g. promised but unpaid subsidy amounts). 

Referring to FIG. 6, a table 600 represents an embodiment of the 
transaction database 250 (FIG. 2) and/or the transaction database 350 (FIG. 3). The 
table 600 includes entries 602, 604 and 606, each defining a transaction with a vendor 
server. Typically, the transaction includes a purchase of items by a customer. Those 
skilled in the art will understand that the table 600 may include any number of entries. 
The table 600 also defines fields for each of the entries 602, 604 and 606. The fields 
specify (i) a transaction identifier 620 that uniquely identifies the transaction, (ii) a 
time 622 of the transaction, (iii) the items ordered 624, (iv) credit card information 
626 that may define a credit card account that was charged to pay for the items 
purchased, (v) an amount charged 628 for the items, (vi) a delivery address 630 for 
the items, and (vii) a customer identifier 632 (if any) that identifies the customer that 
made the purchase. Other forms of payment may be used besides a credit card 
account. For example, debit accounts or "electronic cash" may be used to render 
payment. 

Referring to FIG. 7, a table 700 represents an embodiment of the 

subsidizer database 260 (FIG. 2). The table 700 includes entries 702, 704 and 706, 

each defining a subsidizing vendor that may subsidize purchases. Such information 

may be determined when a subsidizing vendor registers for participation in the 

subsidizing program described herein. Those skilled in the art will understand that the 

table 700 may include any number of entries. The table 700 also defines fields for 

each of the entries 702, 704 and 706. The fields specify (i) a subsidizing vendor 

identifier 720 that uniquely identifies the subsidizing vendor, (ii) a name 722 of the 

subsidizing vendor, (iii) an account 724 used to pay for the subsidies, (iv) an amount 
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owed 726 by the subsidizing vendor, and (v) a rank 728 used to prioritize subsidizing 
vendors and/or subsidies from those subsidizing vendors. The ranks may be 
established periodically (e.g. once per year) or substantially continuously based on 
various criteria. For example, the ranks may be adjusted dynamically based on the 
acceptance rates of offers from the subsidizing vendors and/or amount of funds the 
subsidizing vendors have provided in connection with their offers. 

Referring to FIG. 8, a table 800 represents an embodiment of the offer 
rules database 270 (FIG. 2). The table 800 includes entries 802, 804, 806, 808 and 
810, each defining an offer rule. When an offer rule is satisfied during a transaction, 
the vendor provides an offer for a specified benefit, such as a subsidy. Such 
information may be determined when a subsidizing vendor registers for participation 
in the subsidizing program described herein. Those skilled in the art will understand 
that the table 800 may include any number of entries. The table 800 also defines 
fields for each of the entries 802, 804, 806, 808 and 810. The fields specify (i) an 
offer mle identifier 820 that uniquely identifies the offer rule, (ii) a subsidizing vendor 
identifier 822 that uniquely identifies the subsidizing vendor, (iii) a subsidy amount 
824, (iv) when the offer rule is effective 826 (i.e. when the offer rule is satisfied), and 
(v) an additional transaction 828 that is required of the customer in exchange for the 
subsidy. As described below, several types of transactions, such as additional 
purchases or initiating service agreements, may be required of the customer. 

Referring to FIG. 9, a table 900 represents an embodiment of the offers 

database 280 (FIG. 2). The table 900 includes entries 902, 904, 906, 908 and 910, 

each defining an offer for a subsidy. The offer was provided to a customer during a 

transaction of the customer with the vendor. Those skilled in the art will understand 

that the table 900 may include any number of entries. The table 900 also defines 
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fields for each of the entries 902, 904, 906, 908 and 910. The fields specify (i) an 
offer identifier 920 that uniquely identifies the offer, (ii) a transaction identifier 922 
that uniquely identifies the transaction during which the offer was provided, (iii) a 
subsidizing vendor identifier 924 that uniquely identifies the subsidizing vendor, (iv) 
an identifier of an offer rule 926 that was applied during the transaction, (v) a subsidy 
amount 928, (vi) a total price 930 that the customer would have to pay without the 
subsidy, (vii) a total price 932 that the customer would have to pay with the subsidy, 
and (viii) whether the offer was accepted 934. As described above with reference to 
FIG. 8, offer rules define specific subsidies. Thus, the identifier of an offer rule 
stored in field 926 may be used to determine a corresponding subsidy amount. 

Referring to FIG. 10, a table 1000 represents a record of an 
embodiment of the offer summary database 290 (FIG. 2). The offer summary 
database 290 typically includes a plurality of records, each defining a summary of 
offers for subsidies that have been provided on behalf of a subsidizing vendor. The 
table 1000 includes a subsidizing vendor identifier 1002 that uniquely identifies the 
subsidizing vendor, a total number of offers provided 1004 on behalf of the 
subsidizing vendor, a total number of those offers that were accepted 1006, and a total 
amount 1008 of the subsidies due in connection with accepted offers. 

The table 1000 also includes entries 1010 and 1012, each defining 

offers provided due to satisfaction of an offer rule of the subsidizing vendor. Those 

skilled in the art will understand that the table 1000 may include any number of 

entries. The table 1000 also defines fields for each of the entries 1010 and 1012. The 

fields specify (i) an offer rule identifier 1020 that uniquely identifies the offer rule, (ii) 

a number 1022 of offers-provided due to the offer rule, (iii) a number 1024 of these 

offers that were accepted, (iv) an amount 1026 of the subsidies due in connection with 

15 



these accepted offers. If desirable, the information stored in the offer summary 
database 290 (FIG. 2) may be organized by the vendor through which the offer was 
provided. Such an embodiment would allow a comparison of the acceptance rate 
(number of offers accepted / number of offers provided) of offers at different vendors. 

Referring to FIG. 1 1 , a table 1 100 represents an embodiment of the 
item database 340 (FIG. 3). The table 1 100 includes entries 1 102 and 1 104, each 
defining an item sold via a vendor server. Those skilled in the art will understand that 
the table 1 1 00 may include any number of entries. The table 1 1 00 also defines fields 
for each of the entries 1 102 and 1 104. The fields specify (i) a item identifier 1 120 
that uniquely identifies the item, (ii) an item description 1 122, (iii) an item price 1 124 
for which the item is typically sold, and (iv) an availability 1 126 of the item which 
may be based on an inventory level of the item. 

Referring to FIG. 12, a flow chart 1200 illustrates an embodiment of a 
method for providing an offer for a benefit (e.g. a reduced price) to a customer that is 
to purchase items from a vendor. In one embodiment, the illustrated method is 
performed by a vendor server after the customer has accessed a web page generated 
and/or controlled by the vendor server. In another embodiment, the illustrated method 
is performed by a vendor server after a customer brings items he wishes to purchase 
to a POS terminal. 

The vendor server receives an indication that the customer is to 

purchase items from the web site of the vendor (step 1202). For example, after a 

customer accesses a web site of the vendor, the customer may select one or more 

items to purchase, and "click" a button that indicates that the customer desires to 

purchase the selected items. The act of clicking could generate a signal that the 

vendor server interprets as an indication that the customer is to purchase the selected 
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items. In another embodiment, the act of accessing the web site could generate a 
signal that the vendor server interprets as an indication that the customer is to 
purchase the selected items. In yet another embodiment, a bar code scanner reads bar 
codes on items the customer brings to a POS terminal. The bar code scanner then 
generates a signal that the vendor server interprets as an indication that the customer 
is to purchase the selected items. The item database 340 (FIG. 3) would provide 
relevant details about each indicated item. Those skilled in the art will understand 
still other types of appropriate indications. 

The vendor server then transmits the indication of the items to the 
controller 110 (step 1204). In response, the controller transmits and the vendor server 
receives an indication of an offer for a subsidy from a subsidizing vendor (step 1206). 
This indication may include an indication of a subsidy amount. For example, 
referring again to FIG. 8, the field 824 specifies a subsidy amount for an offer rule, 
and such data could be included in the indication of an offer for a subsidy. The 
indication may also include an indication of a transaction the customer is required to 
perform in exchange for receiving the subsidy amount. The field 828 (FIG. 8) 
specifies such a required transaction. 

The vendor server provides the customer with an offer for the subsidy 
(step 1208). For example, the POS terminal may display a textual representation of 
the offer, which is read by the customer or read to the customer by a cashier. In 
another embodiment, the web page may display text describing the subsidy. The web 
page may be dynamically modified to include a button that, when clicked, indicates 
acceptance of an offer for a subsidy. Alternatively, the offer may be transmitted to 
the customer via email, telephone or other means. 
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A response to the offer is received (step 1210). For example, the 
customer or cashier may actuate a button that generates a representative signal for the 
POS terminal. In another embodiment, the customer may click a button on the web 
page or click on a hyperlink on the web page. If it is determined that the offer is not 
5 accepted (step 1212), then the transaction is processed conventionally (step 1214). 
For example, the items are to be purchased for the conventional total price, a credit 
card number is received and the corresponding credit card account is charged 
appropriately. 

If it is determined that the offer is accepted (step 1212), then an 

10 indication of the acceptance is transmitted to the controller 110 (step 1216) and the 

customer is charged a reduced price for the items (step 1218). Charging a reduced 

price may comprise charging the conventional (i.e. unreduced) price followed by 

crediting the customer a discount amount. For example, if the items are normally sold 

for $25 (as determined by prices specified by the item database 340), then $25 is 

15 charged to a credit card account of the customer, and a discount amount (perhaps $25 

as well) is credited to the credit card account. 

Referring to FIG. 13, a flow chart 1300 illustrates an embodiment of a 

method for providing an offer for a benefit to a customer. In one embodiment, the 

controller 1 10 (FIG. 1) performs the illustrated method after the customer has 

20 accessed a web page generated and/or controlled by the vendor server. In another 

embodiment, the controller 110 performs the illustrated method after a customer 

brings items he wishes to purchase to a POS terminal. 

The controller 110 receives an indication that the customer is to 

purchase items from a first vendor (step 1302). For example, a customer may bring 

25 items to purchase to a POS terminal, at which point the items are scanned by a bar 
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code scanner. The POS terminal in turn transmits an indication of the items to the 
vendor server, which in turn transmits the indication to the controller 110 (step 1204 
of FIG. 12), which receives the indication. In another embodiment, after the customer 
accesses a web site, the customer may select one or more items to purchase, and 
"click" a button that indicates that the customer desires to purchase the selected items. 
The act of clicking could generate a signal that is transmitted via the vendor server to 
the controller 1 10. Alternatively, the customer terminal may include "client-side" 
software that detects various types of customer activity and in response generates 
signals and transmits the signals via the vendor server to the controller 110. The 
controller 110 interprets the signal as an indication that the customer is to purchase 
the selected items. In another embodiment, the act of accessing the web site could 
generate a signal that the controller 110 interprets as an indication that the customer is 
to purchase the selected items. Those skilled in the art will understand still other 
types of appropriate indications. 

In response to the indication that the customer is to purchase items 
from the first vendor, the controller 110 transmits to the vendor server an indication of 
an offer for a subsidy from a second vendor (step 1304). The controller 110 may then 
create an entry in the offers database 280 (FIG. 2) to record the offer. In particular, 
the total price with subsidy may be calculated by subtracting the subsidy amount from 
the total price of the items. The controller 110 may also create an appropriate record 
of the offer summary database 290 (FIG. 2). The controller 110 subsequently 
receives an indication of the customer response (step 1306) from the vendor server. 
This response is also recorded in the appropriate entry of the offers database 280. If 
the customer did not accept the offer (step 1308), the transaction is processed 
conventionally (step 1310). 
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If the customer accepted the offer, the controller 1 10 provides funds to 
the first vendor (step 1312). As described below, the funds provided to the first 
vendor may equal or exceed the amount of reduction in price of the customer's 
purchase. The controller 110 may provide funds a short time after the offer is 
5 accepted (e.g. substantially immediately). Alternatively, the controller 110 may 

provide funds periodically (e.g. in accordance with a periodic remittance cycle). For 
example, the controller 110 may maintain a running balance of funds owed to various 
vendors. At the end of the month, the controller would transmit the aggregate amount 
y to the appropriate vendor or vendors. The step of providing funds may comprise 

Ljl 10 crediting an account corresponding to the first vendor. Alternatively, providing funds 

fy may comprise initiating a transfer of funds (e.g. a "wire transfer") to an account 

M corresponding to the first vendor. 

O In another embodiment described in the parent application, U.S. Patent 

H Application No. 09/2 1 9,267 entitled "METHOD AND APPARATUS FOR 

S 1 5 FACILITATING ELECTRONIC COMMERCE THROUGH PROVIDING CROSS- 

BENEFITS DURING A TRANSACTION", filed on December 23, 1998, the 
controller 1 10 provides funds to the customer by crediting an account of the customer. 

In exchange for the subsidy, the customer is obligated to participate in 
a transaction with the second vendor. Accordingly, the controller 110 facilitates the 
20 required transaction between the customer and the second vendor (step 1314). For 
example, the controller 110 may provide, directly or indirectly, a form for the 
customer to complete. In another embodiment, the controller 110 may initiate the 
transfer of information about the customer (e.g. a service provider of the customer) to 
the second vendor. The controller may record each interaction with a customer in the 
25 transaction database 250 (FIG. 2). 



Referring to FIG. 14, an exemplary web page 1400 illustrates a 
possible means for providing an offer for a benefit and receiving an acceptance of the 
offer. The web page 1400 illustrates an embodiment in which the vendor sells books 
via the World Wide Web. A book that the customer is ready to purchase is indicated 
by text 1402, and a quantity of that book (one book in FIG. 14) is indicated by text 
1404. A price of the books is indicated by text 1406, and similarly a total price (e.g. 
the sum of item prices and any other prices) due from the customer is indicated by 
text 1408. 

A button 1410 is clicked by the customer if the customer desires to 
purchase the specified items and thereby consummate the purchase. Upon clicking 
the button 1410, the items may be immediately deemed as having been purchased by 
the customer. A button 1412 is clicked by the customer if the customer desires to 
accept an offer for a subsidy. Alternatively, actuating the button 1412 may indicate 
that the customer is interested in further information regarding an offer for a subsidy, 
and the customer may subsequently indicate whether he accepts the offer. 

Referring to FIG. 15, a second exemplary web page 1500 allows the 
customer to provide customer information via a form having fields 1502 that receive 
entered text. The customer information is used in applying for a credit card account 
with a credit card issuer. In one embodiment, the web page 1500 may be displayed 
after the customer clicks the button 1412 of FIG. 14. Information that is entered via 
the web page 1500 may be transmitted to the controller 110 upon actuation of a button 
1504. Actuation of the button 1504 may furthermore indicate acceptance of the offer 
for the subsidy. For example, actuation of the button 1504 may indicate a willingness 
to apply for a credit card account, or that the customer has applied for the credit card 
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account. Conversely, actuation of the button 1506 may indicate rejection of the offer 
for the subsidy. 

Referring to FIG. 16, a flow diagram 1600 illustrates the transfer of 
funds among parties in accordance with the present invention. A subsidizing vendor 
1610 provides an amount 1615 of $50 to a central service 1620 (i.e. the entity that 
controls or operates the controller 110). The central service 1620 in turn provides an 
amount 1625 of $45 to a vendor 1630. The vendor 1630 in turn provides an amount 
1635 of $42 to its customer 1640. In the illustrated flow diagram 1600, the central 
service 1 620 and the vendor 1 630 each retain a portion of the funds received from the 
subsidizing vendor 1610. In particular, the central service 1620 retains $5 ($5 = $50 - 
$45) and the vendor 1630 retains $3 ($3 = $45 - $42). The difference between the 
funds received by a party ("funds in") and the funds provided by a party ("funds out") 
in connection with a subsidy may depend on various criteria. In one embodiment, the 
funds out are a predetermined amount less than the funds in. For example, the central 
service 1620 may deduct $5 from each amount provided by the subsidizing vendor 
1610. In another embodiment, the funds out are a predetermined percentage of the 
funds in. For example, the vendor 1630 may deduct 5% of the funds in, and thus the 
funds out form the vendor would be 95% of the funds in to the vendor. Those skilled 
in the art will realize still other ways to calculate the difference between the funds 
received by a party and the funds provided by a party in connection with a subsidy. 

The amount of funds that are retained by the vendor 1630 may be 

based on the amount provided by the subsidizing vendor 1610 and the purchase price 

of the customer 1640. For example, if the subsidizing vendor 1610 is willing to 

provide $50, yet the customer's purchase price is only $20, the difference of $30 ($30 

= $50 - $20) may be retained by the central service 1620 and/or the vendor 1630. The 
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$30 may be allocated among the two parties 1620 and 1630 in numerous manners. 
For example, one party may retain a fixed amount (e.g. $5) and the other party retains 
the remainder. 

In one embodiment, the central service 1620 retains the excess 
between the purchase price of the customer and the amount provided by the 
subsidizing vendor. This amount may be used to augment other offers for subsidies. 
For example, if a subsidizing vendor is willing to provide $50 per customer, and a 
first customer's purchase price is only $20, then the difference of $30 may be retained 
by the subsidizing vendor. A second customer having a purchase price of $80 could 
then receive his items for free, since the subsidy of $50 together with the retained $30 
can offset the $80 purchase price. 

Similarly, the amounts retained from numerous transactions may be 
used to offset other purchase prices. The amounts retained may be collected into a 
"pool" of funds with which to increase specific subsidy amounts, e.g., subsidy 
amounts for purchase prices which exceed a base subsidy amount. Furthermore, 
historical data on past transactions can permit efficient selection of future transactions 
that should receive "augmented" subsidy amounts from the pool of funds. For 
example, historical data can indicate the average transaction amount expected, as well 
as the expected number of subsequent transactions that will be in a predetermined 
range of prices. Thus, the most efficient allocation of the pool of funds among future 
transactions may be determined a priori. 

Referring to FIGS. 17A and 17B, a flow chart 1700 illustrates another 

embodiment of a method for providing an offer for a benefit to a customer that is to 

purchase items from a vendor. The controller 1 1 0 receives an indication that the 

customer is ready to purchase items from the web site of a first vendor (step 1702). A 

23 



customer may indicate his readiness to purchase by, for example, selecting items to 
purchase and actuating a specific button that consummates the purchase of the items. 
Before the customer purchases the items, the controller 1 10 transmits to the vendor 
server an indication of an offer for a subsidy from a second vendor (step 1 704). 
Subsequently, a response from the customer is received (step 1706) via the vendor 
server. For example, the customer may verbally indicate his response to a cashier, the 
cashier actuates a corresponding button on his POS terminal, and the POS terminal 
transmits a signal representing the response to the vender server. 

If it is determined that the offer is not accepted (step 1708), then the 
transaction is processed conventionally (step 1710). If however it is determined that 
the offer is accepted (step 1708), then customer information is received (step 1712). 
Such customer information may be used in providing or facilitating an additional 
transaction that is required of the customer in exchange for the subsidy. 

In one embodiment described in further detail below, in exchange for 
the subsidy the customer agrees to initiate a new service agreement, so that a service 
is provided by the second vendor. Accordingly, the customer information may 
comprise an indication of a service that is provided to the customer (e.g. whether the 
customer has cable television service), or a service provider that provides a service to 
the customer (e.g. which company provides cable television service to the customer). 
The additional transaction may occur after a significant amount of time has elapsed. 
Accordingly, in one embodiment there is a means for determining if the future action 
has occurred. 

Furthermore, a penalty may be assessed against the customer if the 
customer does not perform the required additional transaction. For example, the 
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subsidy to the customer may be canceled and the transaction may then be processed 
conventionally. Alternatively, a penalty fee may be charged to the customer. 

Similarly, a penalty could be assessed if another imposed condition is 
violated. For example, a penalty could be assessed if the items are purchased and 
then returned. Similarly, a returnable purchase could be made a non-returnable 
purchase in exchange for the subsidy or other benefit. Still another penalty would be 
to prevent the customer from receiving subsidies from any merchant in the future. 
Such "blacklisting" could be readily administered by the central controller 110, which 
can store, for each customer, an indication of whether the customer has been 
blacklisted and subsequently identify customers that have been blacklisted. 

The customer information may be received from the customer. In one 
embodiment, the controller 110 can send a request via the vendor server that the 
customer provide customer information. For example, the controller 1 10 may 
transmit a form (e.g. via a web site) including questions to be answered. In response, 
the vendor server would receive answers to the questions, and these answers would 
constitute the customer information from the customer. 

In another embodiment, the customer information may be received 
from a party other than the customer. For example, information regarding the 
customer may be received from a third-party database (e.g. a list of addresses to 
provide a location of the customer, a credit reporting agency). Alternatively, 
customer information may be received from an ISP (Internet Service Provider), which 
can provide information such as an Internet address (e.g. email address or IP address) 
of the customer. 

In still another embodiment, the customer information may be received 

via a "cookie" stored on a customer terminal (e.g. a computer of the customer). Those 
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skilled in the art will understand that a great variety of data may be stored in such 
cookies, and information may be stored in the cookie in response to various events 
such as the web sites that have been visited by the customer. 

In another embodiment, the customer information may comprise the 
telephone number of the customer, as determined from an ANI (Automatic Number 
Identification) signal received from a telephone the customer has used. 

Once customer information is received, it may be stored by the 
controller in the customer database 230 (FIG. 2). Accordingly, information stored in 
this manner would be more readily accessible in the future, even by new vendors and 
subsidizing vendors that had not previously interacted with the customer. 

The controller 110 may verify whether the customer information is 
accurate and complete (step 1714). For example, if the information is provided by the 
customer, it can be advantageous to assure that the customer information is not false. 
To provide a further incentive for the customer to provide accurate customer 
information, a penalty may be assessed against the customer if the customer 
information is not accurate. For example, if it is determined that the customer 
information is not accurate (step 1716), the subsidy to the customer may be canceled 
and the transaction is processed conventionally (step 1710). Alternatively, a penalty 
fee may be charged to the customer if it is determined that the customer information is 
not accurate. In such an embodiment, it may be further advantageous to verify the 
customer information before the purchase is consummated. Thus, the threat that the 
subsidy will not be forthcoming can encourage the customer to provide accurate and 
complete information. 

If it is determined that the customer information is accurate (step 

1716), then the controller 110 determines the amount of the subsidy (step 1718). The 
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subsidy amount is typically stored in the offer rules database 270 (FIG. 2). The 
subsidy amount may be, for example, a predetermined amount or a predetermined 
percentage (e.g. a predetermined percentage of the total price). In one embodiment, 
the subsidy amount may also be limited, such that the price charged cannot be lower 
than zero (i.e. the subsidy may not include a credit). For example, a subsidy amount 
may be "up to $100 off, but no more than the total price". The subsidy amount is 
provided to the first vendor (step 1720) as described above with respect to step 1312 
of FIG. 13. 

Referring to FIGS. 18A and 18B, a flow chart 1800 illustrates another 
embodiment of a method for providing an offer for a benefit to a customer that is to 
purchase items from a first vendor. The controller 110 receives a signal via the 
vendor server indicating that the customer is ready to "check out" his virtual 
"shopping cart" of items on a web site of the first vendor (step 1802). As is 
understood by those skilled in the art, a shopping cart of items on a web site defines a 
set of items the customer desires to purchase. Checking out the shopping cart 
indicates a desire to proceed with purchasing the selected items. Those skilled in the 
art will understand that there are still other ways for a customer to indicate that he is 
to purchase items. 

Before the customer purchases the items, the controller 110 transmits 
to the vendor server an offer for a reduction in the total price in exchange for signing 
up for a service with a second vendor (step 1 804). For example, the service may be 
telephone service, Internet service, banking services, credit card account services, 
insurance service, securities trading service, satellite television service, or cable 
television service. Accordingly, the second vendor would be a provider of such 
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services, and the customer would be requested to participate in a transaction (e.g. 
initiate a service agreement with) with the second vendor. 

Subsequently, a response from the customer is received (step 1 806) via 
the vendor server. If it is determined that the offer is not accepted (step 1808), then 
the transaction is processed conventionally (step 1810). If however it is determined 
that the offer is accepted (step 1 808), then a current service provider of the customer 
(i.e. a party that provides a specified service to the customer) is determined (step 
1812). The customer may be asked to provide information of the current provider, or 
this information may be determined from other sources. For example, one or more 
databases may be accessed to determine the long distance telephone service provider 
of the customer. Alternatively, the second vendor may allow access to a database of 
its existing customers to ascertain whether the customer is included in that database: 

If it is determined that the customer has a service provider (step 1814), 
and it is determined that the second vendor already provides the customer with the 
specified service (step 1816), then the transaction is processed conventionally (step 
1810). If it is determined that the customer has a service provider (step 1814), but it 
is determined that the second vendor does not provide the customer with the specified 
service (step 1816), then the customer must have a service agreement with another 
service provider. Accordingly, the existing service agreement is canceled (step 1818). 

If it is determined that the customer does not have a service provider of 

the specified service at all (step 1814), (or if the controller 110 will cancel or has 

canceled the existing service agreement) then a new service agreement is initiated 

with the second vendor (step 1820). Thus, the second vendor has acquired a new 

customer, either by signing up the customer for a new service or by switching 

providers of the specified service that is provided to the customer. In exchange, the 
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total price of the shopping cart of items is reduced by the amount of the subsidy (step 
1 822), and controller 1 1 0 directs the vendor server to sell the items for this reduced 
total price (step 1824). 

Referring to FIG. 19, a flow chart 1900 illustrates another embodiment 
of a method for providing an offer for a benefit to a customer that is to purchase items 
from a first vendor. The controller 110 receives an indication that the customer is 
ready to purchase items from a first vendor (step 1902). The controller 110 may also 
receive customer information (step 1 904), as described above. The customer 
information may comprise, for example, a location of the customer or a current 
service provider of the customer. 

A set of subsidies for which the customer may be eligible is 
determined (step 1906). In one embodiment, the set of subsidies is determined based 
on customer information. For example, upon reference to the customer information, 
one or more offer rules may be satisfied. The subsidies corresponding to the satisfied 
rules would then be included in the set of subsidies. In another embodiment, the offer 
rules may be satisfied without reference to customer information. For example, an 
offer rule may be satisfied if the total price of the items (or the price of any of the 
item) is greater than (or less than) a predetermined threshold. An offer rule may also 
be satisfied if a particular item is purchased. In yet another embodiment, one or more 
subsidizing vendors may be contacted, customer information may be transmitted to 
the subsidizing vendors, and in response the subsidizing vendors may transmit to the 
controller 110 a description of a subsidy to offer. In still another embodiment, a 
subsidizing vendor may be selected (e.g. based on a preferential ranking) and a 
subsidy from this subsidizing vendor is selected. 
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Offers for each of the subsidies may be provided to the customer (step 
1908) for the customer to select one (or more). For example, each offer may be listed 
on a web page, and the customer must click a hyperlink corresponding to his desired 
offer. The offers may be provided substantially simultaneously, allowing the 
customer to evaluate all offers before selecting an offer. Alternatively, the offers may 
be provided sequentially to the customer. In such an embodiment, the customer 
would be provided with additional offers only after rejecting one or more offers 
provided to him. The order in which offers are provided may be determined by the 
rank of each subsidizing vendor that provides the offer. The controller 1 10 may 
ascertain the rank of each offer by referencing the field 728 (FIG. 7) for each 
subsidizing vendor that provides the offer. The offers could then be provided in a 
sequence defined by the rank of each offer. 

The customer selection is received (step 1910) and the corresponding 
subsidy amount is transferred to the first vendor (step 1912). Alternatively, the 
customer may be similarly prompted to select a vendor from a plurality of vendors, 
and the customer would subsequently be provided with an offer for a subsidy from the 
selected vendor. 

The controller 110 may select one (or more) offers to provide to a 
customer based on various criteria. For example, the offer with the highest historical 
acceptance rate may be selected. The historical acceptance rate may be calculated 
based on data derived from the fields 1022 and 1024 (FIG. 10). Similarly, the offer 
with the highest profit (e.g., to the vendor or subsidizing vendor) may be selected. 

The customer may select two or more offers, thereby generally 

receiving more of a benefit than if he had selected only one offer. For example, the 

customer may select offers that require him to (i) sign up for a particular credit card 
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account, (ii) sign up for a particular satellite television service, and (iii) switch to a 
new provider of cellular telephone service. The controller 1 1 0 could charge the 
accounts of each of three subsidizing vendors, and the aggregate amount charged 
could be used to reduce the price charged to a customer for a purchase. 

The customer described herein may, in one embodiment, comprise a 
group of customers such as a group dining at a restaurant. In such an embodiment, an 
offer may be accepted by a plurality of customers. For example, if an offer for a 
subsidy includes a $75 subsidy amount, then if two customers accept the price of the 
purchase may be reduced by $150 ($150 = $75 x 2). 

Referring to FIGS. 20A and 20B, a flow chart 200 illustrates another 
embodiment of a method for providing an offer for a benefit to a customer that is to 
purchase items from a first vendor. Specifically, in the illustrated embodiment a 
customer may be allowed to add more items if a subsidy amount of an offer exceeds 
the total price of the items he had already selected. 

The vendor server receives an indication that the customer is to 
purchase a first set of items from the vendor (step 2002). The vendor server then 
transmits the indication of the items to the controller 110 (step 2004). In response, the 
controller 110 transmits and the vendor server receives an indication of an offer for a 
subsidy from a subsidizing vendor (step 2006). This indication may include an 
indication of a subsidy amount. 

The vendor server provides the customer with an offer for a subsidy 
(step 2008). A response to the offer is received (step 2010). If it is determined that 
the offer is not accepted (step 2012), then the transaction is processed conventionally 
(step 2014). 
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If it is determined that the offer is accepted (step 2012), then an 
indication of the acceptance is transmitted to the controller 110 (step 2016). If the 
subsidy amount is greater than the total price of the set of items (step 201 8), then the 
transaction is suspended (step 2020) and the customer is instructed to select an 
5 additional set of items (step 2022). The customer may be instructed in the same way 
the customer may be provided with an offer for a subsidy. For example, a POS 
terminal may display a textual representation of the instructions, which is read by the 
customer or read to the customer by a cashier. In another embodiment, a web page 
p may display text describing the instructions. 

~? 

mJ 10 Subsequently, the vendor server receives an indication of a second set 

%. i 

j! of items the customer has selected (step 2024). The second set and the first set are 

then purchased for a reduced purchase price. The customer is charged a reduced price 
o (step 2026) which may be zero (e.g. if the subsidy amount exceeds the sum of the 

w 

fy prices of the first and second sets of items). 

ft ; 

iD 15 Referring to FIG. 2 1 , a table 2 1 00 illustrates data used in another 

embodiment of the present invention in which a subsidy amount may be applied over 

time. The table 2100 represents information that may be stored in the customer 

database 230 and/or the customer database 330. Use of the information in the table 

2100 is described in detail below with respect to FIG. 22. A customer identifier 2102 

20 uniquely identifies a customer who is due to receive the subsidy amount over time. 

Credit card information 2104, such as a credit card number and account type, specify 

an account which may be repeatedly credited to grant the customer the benefit due. 

The number of credits remaining 2106, frequency 2108 and next credit date 2110 

specify when the customer may receive another credit to his account. The amount 

25 credited to the specified credit card account is indicated by reference numeral 2112. 
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Referring to FIG. 22, a flow chart 2200 illustrates another embodiment 
of a method for providing an offer for a benefit to a customer. Specifically, in the 
illustrated embodiment a subsidy amount is applied over time by repeatedly crediting 
a credit card account. After the credit card account is credited (step 2202), the 
controller 110 sets the next credit date (step 2203) which may be readily calculated 
from the current date and the frequency 2108 (FIG. 21). The controller 110 then 
waits until the next credit date (step 2204) and determines whether there are any more 
credits to apply (step 2206). If there are more credits remaining, then the controller 
110 also determines whether the customer has met all of his obligations (step 2208). 
For example, the customer may have been required to sign up for and maintain a 
cellular telephone account with a particular subsidizing vendor. In such a situation, 
the controller 110 would determine whether the customer has canceled the required 
cellular telephone account. If all obligations have been met by the customer, then the 
account is credited again (step 2202). 

In the above embodiment, additional or unused subsidy amounts may 
be, e.g., presented to the customer in the form of a store credit (applied against future 
purchases from the vendor). Alternatively, the unused subsidy amounts may be 
forfeited. 

Although the present invention has been described with respect to a 
preferred embodiment thereof, those skilled in the art will note that various 
substitutions may be made to those embodiments described herein without departing 
from the spirit and scope of the present invention. 
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